perm filename LISP.BUG[BUG,LSP]11 blob
sn#681161 filedate 1982-10-10 generic text, type C, neo UTF8
COMMENT ⊗ VALID 00042 PAGES
C REC PAGE DESCRIPTION
C00001 00001
C00007 00002 BUG-LISP and LISP-FORUM
C00008 00003 ∂20-Aug-82 2041 George J. Carrette <GJC at MIT-MC> fixes to maclisp
C00009 00004 ∂21-Aug-82 1157 John Ruttenberg <Ruttenberg at YALE> Bug in setf and arraycall
C00012 00005 ∂21-Aug-82 1207 Jonathan Rees <Rees at YALE> (SSTATUS SYNTAX #/| ...)
C00013 00006 ∂22-Aug-82 1558 Alan Bawden <ALAN at MIT-MC> (SSTATUS SYNTAX #/| ...)
C00015 00007 ∂22-Aug-82 1647 Alan Bawden <ALAN at MIT-MC> push/defvst interaction?
C00017 00008 ∂22-Aug-82 1923 John Ruttenberg <Ruttenberg at YALE> Re: push/defvst interaction?
C00019 00009 ∂23-Aug-82 0001 George J. Carrette <GJC at MIT-MC> push/defvst interaction?
C00022 00010 ∂23-Aug-82 1409 Alan Bawden <ALAN at MIT-MC> push/defvst interaction?
C00025 00011 ∂24-Aug-82 1545 Glenn S. Burke <GSB at MIT-ML> distribution request
C00026 00012 ∂24-Aug-82 1939 Greg Skinner <EE.GDS at MIT-OZ> Lisp problem
C00028 00013 ∂24-Aug-82 1939 Barry Margolin at MIT-MULTICS Re: Lisp problem
C00030 00014 ∂27-Aug-82 1306 Glenn S. Burke <GSB at MIT-ML> (SSTATUS SYNTAX #/| ...)
C00032 00015 ∂29-Aug-82 2313 GSB@MIT-ML new format installed on MC and OZ
C00033 00016 ∂30-Aug-82 1613 JonL at PARC-MAXC Re: fixes to maclisp
C00035 00017 ∂30-Aug-82 2236 Kent M. Pitman <KMP at MIT-MC> FORMAT losing
C00037 00018 ∂31-Aug-82 2102 Glenn S. Burke <GSB at MIT-MC>
C00038 00019 ∂31-Aug-82 2107 Glenn S. Burke <GSB at MIT-MC>
C00039 00020 ∂31-Aug-82 2310 George J. Carrette <GJC at MIT-MC> hacking/assembly maclisp
C00041 00021 ∂01-Sep-82 1043 Robert P. Krajewski <RpK at MIT-ML> WITH-OPEN-FILE
C00043 00022 ∂01-Sep-82 1333 Kent M. Pitman <KMP at MIT-MC> WITH-OPEN-FILE
C00044 00023 ∂01-Sep-82 1403 Alan Bawden <ALAN at MIT-MC> WITH-OPEN-FILE
C00047 00024 ∂01-Sep-82 1958 Glenn S. Burke <GSB at MIT-MC> renamef failure
C00048 00025 ∂01-Sep-82 2045 FEINBERG at CMU-20C renamef failure
C00049 00026 ∂01-Sep-82 2227 Kent M. Pitman <KMP at MIT-MC>
C00050 00027 ∂06-Sep-82 1540 Devon S. McCullough <Devon at MIT-ML>
C00052 00028 ∂06-Sep-82 1544 Kent M. Pitman <KMP at MIT-MC>
C00053 00029 ∂06-Sep-82 1827 Robert Elton Maas <REM at MIT-MC> (LISTEN)
C00054 00030 ∂07-Sep-82 1329 Glenn S. Burke <GSB at MIT-ML> (LISTEN)
C00055 00031 ∂07-Sep-82 1737 Glenn S. Burke <GSB at MIT-MC> suspend tty code fix (tops-20 vts)
C00057 00032 ∂07-Sep-82 1738 Skef Wholey <Wholey at CMU-20C> Complr's losing lossage, of course
C00059 00033 ∂07-Sep-82 2221 Glenn S. Burke <GSB at MIT-MC> load-byte/deposit-byte miscompilation
C00060 00034 ∂09-Sep-82 0021 GSB@MIT-ML previous patch, to OPNT2
C00061 00035 ∂13-Sep-82 1324 Kent M. Pitman <KMP at MIT-MC>
C00063 00036 ∂14-Sep-82 1102 Jonathan Alan Solomon <JSol at USC-ECLC>
C00065 00037 ∂14-Sep-82 2252 Stavros M. Macrakis <MACRAK at MIT-MC> < WNA msg
C00066 00038 ∂17-Sep-82 1643 Glenn S. Burke <GSB at MIT-ML> (status ttysize) on 20X
C00067 00039 ∂17-Sep-82 1658 GSB@MIT-ML (status ttysize) bug, 20x
C00068 00040 ∂17-Sep-82 1701 GSB@MIT-ML previous patch
C00070 00041 ∂01-Oct-82 0404 Kent M. Pitman <KMP at MIT-MC> More data
C00072 00042 ∂02-Oct-82 1234 Alan Bawden <ALAN at MIT-MC> ALPHALESSP: More data
C00078 ENDMK
C⊗;
BUG-LISP and LISP-FORUM
∂20-Aug-82 2041 George J. Carrette <GJC at MIT-MC> fixes to maclisp
Date: 20 August 1982 23:27-EDT
From: George J. Carrette <GJC at MIT-MC>
Subject: fixes to maclisp
To: JONL at MIT-MC
cc: BUG-LISP at MIT-MC
Can you tell us the best way to assemble a Maclisp on a tops-20
so that we can put in the various accumulated fixes in the version
on OZ? For example, the MT fix to suspend. Thanks.
∂21-Aug-82 1157 John Ruttenberg <Ruttenberg at YALE> Bug in setf and arraycall
Date: 14-Aug-82 10:55AM-EDT (Sat)
From: John Ruttenberg <Ruttenberg at YALE>
Subject: Bug in setf and arraycall
To: Bug-Lisp at MIT-MC
Seems to be a problem with push and arraycall. Here's the source file:
(defvst bug-st
(a = (*array () t 10))
)
(defmacro bug-st-ai (self index)
`(arraycall t (bug-st-a ,self) ,index))
(defun bug (self member index)
(push member (bug-st-ai self index)))
(setq b (cons-a-bug-st))
(bug b 'a 4)
(bug b 'a 4)
And here's how Maclisp takes it:
Yale Haclisp 82 (in Maclisp 2088)
> (defvst bug-st
(a = (*array () t 10))
)
;Loading DEFVST 3
;Loading EXTMAC 183
;Loading ERRCK 20
;Loading VECTOR 64
;Loading DEFVSX 85
BUG-ST
>(defmacro bug-st-ai (self index)
`(arraycall t (bug-st-a ,self) ,index))
BUG-ST-AI
>(defun bug (self member index)
(push member (bug-st-ai self index)))
BUG
>(setq b (cons-a-bug-st))
#{BUG-ST A #T-10-71712}
>(bug b 'a 4)
(A)
>(bug b 'a 4)
;G0017 UNBOUND VARIABLE
;BKPT UNBND-VRBL
> (baktrace)
BAKTRACE
+INTERNAL-UBV-BREAK← ARRAYCALL← PUSH← BUG←
It seems especially odd to me that things should blow up only after the
second call to bug.
-------
∂21-Aug-82 1207 Jonathan Rees <Rees at YALE> (SSTATUS SYNTAX #/| ...)
Date: Saturday, 14 August 1982 00:31-EDT
From: Jonathan Rees <Rees at YALE>
To: Bug-Lisp at MIT-MC
Subject: (SSTATUS SYNTAX #/| ...)
Cc: Ellis at YALE, Ruttenberg at YALE
Trying to set the syntax of | doesn't work.
(SSTATUS SYNTAX #/| 2.) ;2 is syntax of %, :, etc.
2
'|
/↑T
Vertical bars in symbols read as control-T's.
∂22-Aug-82 1558 Alan Bawden <ALAN at MIT-MC> (SSTATUS SYNTAX #/| ...)
Date: 22 August 1982 18:59-EDT
From: Alan Bawden <ALAN at MIT-MC>
Subject: (SSTATUS SYNTAX #/| ...)
To: Rees at YALE
cc: BUG-LISP at MIT-MC, Ellis at YALE, Ruttenberg at YALE
Date: Saturday, 14 August 1982 00:31-EDT
From: Jonathan Rees <Rees at YALE>
(SSTATUS SYNTAX #/| 2.)
2
'|
/↑T
This is because (SSTATUS SYNTAX) doesn't know enough to set up the character
translation when it turns off a macro character. You can either do (SSTATUS
CHTRAN #/| #/|) immediately afterwords, or use (SETSYNTAX #/| 2. #/|) instead.
I started to fix this, but the code is too ugly to be believed.
∂22-Aug-82 1647 Alan Bawden <ALAN at MIT-MC> push/defvst interaction?
Date: 22 August 1982 19:29-EDT
From: Alan Bawden <ALAN at MIT-MC>
Subject: push/defvst interaction?
To: BUG-LISP at MIT-MC
cc: Ruttenberg at YALE
Date: 14-Aug-82 10:55AM-EDT (Sat)
From: John Ruttenberg <Ruttenberg at YALE>
It seems especially odd to me that things should blow up only after the
second call to bug.
A smaller case of the bug:
(defvst bug-st
(a = (*array () t 10))
)
(defun bug (self member index)
(push member (arraycall t (bug-st-a self) index)))
(setq b (cons-a-bug-st))
(bug b 'a 4)
(bug b 'a 4)
After the first call to BUG it's definition has been changed to be:
(defun bug (self member index)
(push member (arraycall t <gensym> index)))
This is probably an artifact of PUSH being a fexpr (but thinking like a macro),
bug it also seems to depend heavily on the source of the array being a defvst
accessor. It doesn't happen if you are using defstruct instead. Perhaps those
responsible for defvst/push will step forward and fix?
∂22-Aug-82 1923 John Ruttenberg <Ruttenberg at YALE> Re: push/defvst interaction?
Date: 22-Aug-82 10:22PM-EDT (Sun)
From: John Ruttenberg <Ruttenberg at YALE>
Subject: Re: push/defvst interaction?
To: Alan at MIT-MC
Cc: Bug-Lisp at MIT-MC
In-Reply-To: Bawden's message of 22 August 1982 19:29-EDT
It doesn't happen if you are using defstruct instead.
We would use defstruct, except that using it into named hunks
makes it want to use some version of defvst that we don't have
here. Where are the authorative up to date sources for things
like defstruct and defvst? I'd like to know if we can get
this fix and others like it.
Also note that I don't seem to be able to compile the bug infested
code. (Same problem - some unbound gensym in the push expression).
-------
∂23-Aug-82 0001 George J. Carrette <GJC at MIT-MC> push/defvst interaction?
Date: 23 August 1982 02:45-EDT
From: George J. Carrette <GJC at MIT-MC>
Subject: push/defvst interaction?
To: Ruttenberg at YALE
cc: ALAN at MIT-MC, BUG-LISP at MIT-MC
As a bit of honest practical advice, I would concur with ALAN in
suggesting that you use DEFSTRUCT in preference to DEFVST.
The story goes like this: DEFVST was supposed to be part of
a package of code which was "NILCOM," common to both NIL and Maclisp,
and presumably to be part of "common-lisp." As it turned out though,
the implementation of all of that "NILCOM" code was too tentative
and kludgy to be worth bringing up in actual VAX NIL, so instead
code like Defstruct (which is de-facto common-lisp)
was brought up. So you see, there can be little
incentive here (at MIT) to support/fix-bugs in code such as DEFVST.
On the other hand, it is quite easy for me to make available to
you an option to defstruct called "EXTEND" which does the same
job as "DEFVST" except that the interface is a lot cleaner,
and it actually works! (It is what RLB and I used last summer to
cross-compile NIL from the pdp-10 to the VAX). You can get it
by FTPing "GJC;SFIX FASL" from the MIT-MC machine. Source is in
"GJC;SFIX >" on MIT-MC.
To answer your question about source code: The most up-to-date
versions of things are on the LIBDOC, LSPSRC, and NILCOM directories
on MIT-MC. The *best* solution seems to be to keep a winning
Maclisp environment working on MIT-OZ, and let people FTP
stuff from there.
-gjc
∂23-Aug-82 1409 Alan Bawden <ALAN at MIT-MC> push/defvst interaction?
Date: 23 August 1982 17:03-EDT
From: Alan Bawden <ALAN at MIT-MC>
Subject: push/defvst interaction?
To: Ruttenberg at YALE
cc: BUG-LISP at MIT-MC
Date: 22-Aug-82 10:22PM-EDT (Sun)
From: John Ruttenberg <Ruttenberg at YALE>
It doesn't happen if you are using defstruct instead.
We would use defstruct, except that using it into named hunks
makes it want to use some version of defvst that we don't have
here. Where are the authorative up to date sources for things
like defstruct and defvst? I'd like to know if we can get
this fix and others like it.
I heve never released a version of defstruct that had anything whatsoever to do
with ANY of the out-of-core (autoloading) MacLisp libraries. There is a
feature that made defstruct a front end for defvst which I have never released
to anyone, but that wouldn't do you any good anyway. Can you send me an
example of a defstruct that tries to load ANYTHING? Up-to-date defstruct FASL
can be found on LISP;STRUCT FASL.
Also note that I don't seem to be able to compile the bug infested
code. (Same problem - some unbound gensym in the push expression).
I'm not surprised that you can't compile it either.
∂24-Aug-82 1545 Glenn S. Burke <GSB at MIT-ML> distribution request
Date: 24 August 1982 18:40-EDT
From: Glenn S. Burke <GSB at MIT-ML>
Subject: distribution request
To: TY at MIT-ML
cc: BUG-LISP at MIT-ML
tar@MIT-ML (Sent by ←←←036@MIT-ML) 08/24/82 14:48:02 Re: Phone message
Steve Cadrak called.
Academic Computing Center
University of Vermont
Burlington, VT 05405
He would like to obtain the latest MACLISP. (He has version 2009)
TOPS-20 version 5.
(802) 656-3910
∂24-Aug-82 1939 Greg Skinner <EE.GDS at MIT-OZ> Lisp problem
Date: 24 Aug 1982 2050-EDT
From: Greg Skinner <EE.GDS at MIT-OZ>
Subject: Lisp problem
To: bug-lisp at MIT-OZ
Subject: LISP problem
Is this a bug or just a feature? (especially (gcd 15 5)
evaluating to 1, while the others seem to evaluate correctly).
Plus, is there any way that LISP can be set so that base 10
numbers are echoed as such? (re 8 = 10 and 10 = 10)
[PHOTO: Recording initiated Tue 24-Aug-82 8:37PM]
TOPS-20 Command processor 4(661)-2
@lisp
LISP 2129
Alloc? n
*
(gcd 15 5)
1
(gcd 30 10)
10
(gcd 8 4)
4
(gcd 60 30)
30
(gcd 50 5)
5
(quotient 50 4)
12
50
50
(quit)
@pop
[PHOTO: Recording terminated Tue 24-Aug-82 8:38PM]
-------
∂24-Aug-82 1939 Barry Margolin at MIT-MULTICS Re: Lisp problem
Date: 24 August 1982 20:56 edt
From: Barry Margolin at MIT-MULTICS
Subject: Re: Lisp problem
Sender: Margolin.Multics at MIT-MULTICS
To: Greg Skinner <EE.GDS at MIT-OZ>
cc: bug-lisp at MIT-OZ
In-Reply-To: Message of 24 August 1982 20:50 edt from Greg Skinner
There were no bugs displayed in that session. By default, Maclisp is in
base 8, and 15(8) = 13(10) (where the notation xx(n) means the numeral
xx in base n), and the GCD of 5(10) and 13(10) is indeed 1. The
variables that control the base that numbers are input and output in are
"base", which is the base that numbers are output in, and "ibase", which
controls the input base. Associated with these is the variable
"*nopoint", which if set to T causes the decimal point that normally
follows decimal numbers on output to be suppressed. Note that any
fixnum that has a trailing decimal point (as in 100.) is also read in in
decimal, regardless of the setting of ibase, so to initially set the
base variables you should say:
(setq base 10.)
(setq ibase 10.)
∂27-Aug-82 1306 Glenn S. Burke <GSB at MIT-ML> (SSTATUS SYNTAX #/| ...)
Date: 27 August 1982 15:51-EDT
From: Glenn S. Burke <GSB at MIT-ML>
Subject: (SSTATUS SYNTAX #/| ...)
To: Rees at YALE
cc: Ellis at YALE, Ruttenberg at YALE, BUG-Lisp at MIT-MC
I believe that SETSYNTAX is what you want here; it assumes that the
choices (bits only, MACRO, SPLICING) are mutually exclusive. (sstatus
syntax ...) only hacks the syntax bits. In obscure applications this
is actually useful (the fact that it doesn't clobber the macro/chtran
entry, that is), because you can do strange and perverse things with
something like "." so that it is still decimal point but also acts
like a special-token (implemented as a reader macro). (I've done this.
It almost works.)
∂29-Aug-82 2313 GSB@MIT-ML new format installed on MC and OZ
From: GSB@MIT-ML
Date: 08/30/82 01:34:11
Subject: new format installed on MC and OZ
GSB@MIT-ML 08/30/82 01:34:11 Re: new format installed on MC and OZ
To: (BUG LISP) at MIT-ML
format 827 has been put on MC and OZ. the file types involved are
FASL, BRACK, FLOAT, NUM, and UMACS. This fixes a fencepost bugs
in ~$ and a misfeature in operator definition via define-format-op,
and maybe some other things which i have since forgotten.
∂30-Aug-82 1613 JonL at PARC-MAXC Re: fixes to maclisp
Date: 30 Aug 1982 16:10 PDT
From: JonL at PARC-MAXC
Subject: Re: fixes to maclisp
In-reply-to: GJC's message of 20 August 1982 23:27-EDT
To: George J. Carrette <GJC at MIT-MC>
cc: JONL at MIT-MC, BUG-LISP at MIT-MC
I've just returned from two weeks travelling (LispConference, AAAI, MIT
visit etc) and I didn't see you at MIT -- are you still there?
There used to be a .CTL file on MIT-XX, PS:<MACLISP>ASSLIS.CTL, which
you could just SUBMIT and it would doo all the rest. It would leave
an *uninitialized* result on SS:<MACLISP>BBLISP.EXE.<nnnn> and also
do an initialization phase leaving PS:<MACLISP>XLISP.EXE.<nnnn> and
PS:<MACLISP>LISP.SYMBOLS.<nnnn>. You then rename XLISP to LISP after
certifying that things are winning. The value of the uninitialized
file is that it's hard to patch the LISP.EXE file with the existing NDDT since
it involves changing file page accessibilities (read-only etc).
∂30-Aug-82 2236 Kent M. Pitman <KMP at MIT-MC> FORMAT losing
Date: 31 August 1982 01:15-EDT
From: Kent M. Pitman <KMP at MIT-MC>
Sender: VP at MIT-MC
Subject: FORMAT losing
To: GSB at MIT-MC
cc: BUG-LISP at MIT-MC
In Maclisp 2122, Format 827. on MIT-MC:
Ignoring the rough points in what these actually ask FORMAT to do ('cuz
there are a few conceptual bugs), these functions do not behave in ways
even remotely resembling what the LispM does with them. For example, the
LispM does not err, pdl-overflow, or complain of missing ~]'s. Simple
tests like (f nil), (f '(a)), (f '(a b)), (f '(a b c)) and likewise for g
should give you a feel for what I'm talking about. G'luck.
(defun f (x)
(lexpr-funcall #'format t "~#[nothing~;~S~;~S and ~S~
~:;~@{~<~% ~1,50:;~#[~1; and~] ~S~>~↑,~}~]" x))
(defun g (x)
(format t "~%;; ~{~<~%;; ~1,50:;~#[~1; and~] ~S~>~↑,~}.~%" x))
-kmp
∂31-Aug-82 2102 Glenn S. Burke <GSB at MIT-MC>
Date: 31 August 1982 23:57-EDT
From: Glenn S. Burke <GSB at MIT-MC>
To: BUG-LISP at MIT-MC
on OZ,
∂31-Aug-82 2107 Glenn S. Burke <GSB at MIT-MC>
Date: 1 September 1982 00:00-EDT
From: Glenn S. Burke <GSB at MIT-MC>
To: BUG-LISP at MIT-MC
on oz, an LH/| page disappears when the job is suspended and restarted.
One gets a memory protection violation...
∂31-Aug-82 2310 George J. Carrette <GJC at MIT-MC> hacking/assembly maclisp
Date: 1 September 1982 02:04-EDT
From: George J. Carrette <GJC at MIT-MC>
Subject: hacking/assembly maclisp
To: JONL at MIT-MC
cc: BUG-LISP at MIT-MC
Thanks for the info, now, I wonder if I have *read* access to the
Maclisp directory on XX? sigh... it is a wonder anything gets done
at MIT inside LCS. Yes, I expected to be at the lisp conference,
but when the time came to leave it seemed more fun to stay at
ATARI and hack up some demo's in NIL on their brand-new 780.
I heard that some of the graphics in TRON were done in Maclisp
on a Foonly (by the way). Remember that bug note/question about
extened objects and arithmetic some months ago? I think it
was from the same guy, Craig Renolds?
Anyway, thats the state of things, I'll be at ATARI again in a little
while and I'll give you a call in Palo Alto, want to see some
3-D graphics in NIL controlled via the flavor system?
[No, I didn't implement a number-compiler for NIL yet, the crunching
stuff is written in (sigh) "C" which gets interfaced to NIL in the
obvious way.]
-gjc
∂01-Sep-82 1043 Robert P. Krajewski <RpK at MIT-ML> WITH-OPEN-FILE
Date: 1 September 1982 13:40-EDT
From: Robert P. Krajewski <RpK at MIT-ML>
Subject: WITH-OPEN-FILE
To: BUG-Lisp at MIT-MC
cc: RpK at MIT-OZ
Does WITH-OPEN-FILE exist in MacLisp ? It would be a very nice
thing to have. I'd define a robust version of it, but I don't
know how MacLisp does UNWIND-PROTECTs and such. (If you take
out the clean-up code, it's very simple.)
This may be a stupid question, but why don't the objects
returned by OPEN accept messages like :TYO, :TYI, :STRING-OUT,
:LINE-OUT, :TRUENAME, and so on ? All they seem to accept are
very general messages that would be handled by the Lisp Machine
SI:VANILLA-FLAVOR -- :PRINT-SELF and others.
``Bob''
∂01-Sep-82 1333 Kent M. Pitman <KMP at MIT-MC> WITH-OPEN-FILE
Date: 1 September 1982 16:27-EDT
From: Kent M. Pitman <KMP at MIT-MC>
Subject: WITH-OPEN-FILE
To: RPK at MIT-MC
cc: BUG-LISP at MIT-MC
There is a package on LIBLSP called IOTA which does what you want. I'm working
on a library of macros and functions to help people trying to hack Lisp
Machine compatibility. Among things in that library will be WITH-OPEN-FILE.
For now, though, IOTA is the thing to use. It's used heavily in lots of Maclisp
systems and works fine. Documentation is in LIBDOC;IOTA >
-kmp
∂01-Sep-82 1403 Alan Bawden <ALAN at MIT-MC> WITH-OPEN-FILE
Date: 1 September 1982 16:56-EDT
From: Alan Bawden <ALAN at MIT-MC>
Subject: WITH-OPEN-FILE
To: RpK at MIT-ML
cc: BUG-LISP at MIT-MC, RpK at MIT-OZ
Date: 1 September 1982 13:40-EDT
From: Robert P. Krajewski <RpK at MIT-ML>
Does WITH-OPEN-FILE exist in MacLisp ? It would be a very nice
thing to have. I'd define a robust version of it, but I don't
know how MacLisp does UNWIND-PROTECTs and such. (If you take
out the clean-up code, it's very simple.)
MacLisp does UNWIND-PROTECT by having an UNWIND-PROTECT special form just like
the LispMachine's. There is no built-in WITH-OPEN-FILE macro, but clearly you
can write your own using UNWIND-PROTECT, or wait until KMP writes one (he'll
think of some screws you never dreamed of I'll bet) or you can convert your
code to using IOTA.
This may be a stupid question, but why don't the objects
returned by OPEN accept messages like :TYO, :TYI, :STRING-OUT,
:LINE-OUT, :TRUENAME, and so on ? All they seem to accept are
very general messages that would be handled by the Lisp Machine
SI:VANILLA-FLAVOR -- :PRINT-SELF and others.
I don't understand this question in the least. The objects returned by OPEN
don't except ANY messages. They are not message recieving objects. They do
have a printed representation, but that isn't accomplished by sending any
messages. You don't do I/O by sending them messages, but by calling functions
like PRINC and TYO and passing them the "file object" as an argument.
∂01-Sep-82 1958 Glenn S. Burke <GSB at MIT-MC> renamef failure
Date: 1 September 1982 22:52-EDT
From: Glenn S. Burke <GSB at MIT-MC>
Subject: renamef failure
To: BUG-LISP at MIT-MC
the IOJRST at RENAM5+6 should be a JFCL. If the RNAMF fails then the
file has been closed but the jfn not released. The IOJRST after the
failing CLOSF will clobber the first error message (and probably not
allow the error to return because iojrst stack hacks probably aren't
additive). I have changed this in the source, someone patch it on
a 20?
∂01-Sep-82 2045 FEINBERG at CMU-20C renamef failure
Date: 1 September 1982 23:36-EDT (Wednesday)
From: FEINBERG at CMU-20C
To: Glenn S. Burke <GSB at MIT-MC>
Cc: BUG-LISP at MIT-MC
Subject: renamef failure
Howdy!
It is patched on OZ.
--Chiron
∂01-Sep-82 2227 Kent M. Pitman <KMP at MIT-MC>
Date: 2 September 1982 01:19-EDT
From: Kent M. Pitman <KMP at MIT-MC>
To: RPK at MIT-MC
cc: BUG-LISP at MIT-MC
I put a package on LIBLSP; (and <LIBLSP> on OZ) called LISPM. Please play
with this and tell me if it gives you any troubles. If no one reports any
bugs in a week or two, I'll announce it to INFO-MACLISP. The file defines
compatibility definitions for DEFSUBST, DOLIST, DOTIMES, MEXP, WITH-OPEN-FILE
and WITH-OPEN-STREAM. Documentation is in LIBDOC;LISPM > and in
OZ:PS:<LIBLSP>LISPM.LSP
-kmp
∂06-Sep-82 1540 Devon S. McCullough <Devon at MIT-ML>
Date: 6 September 1982 18:39-EDT
From: Devon S. McCullough <Devon at MIT-ML>
To: BUG-lisp at MIT-OZ
In lisp in Remote-File 14.0, LMFILE-Remote 18.0, MIT-Specific 10.0,
System 87.19, Experimental ZMail 46.3, microcode 164, No, devon,
on Lisp Machine One:
In the blue manual on page 158, 11.1 describing closures, it says
The form (closure var-list function), where var-list is a list of...
...
the value cells of the symbols. Then function is applied to the ARGUMENT. (This...
in the next-to last paragraph on the page. ARGUMENT should be plural, or I'm mixed up!
∂06-Sep-82 1544 Kent M. Pitman <KMP at MIT-MC>
Date: 6 September 1982 18:38-EDT
From: Kent M. Pitman <KMP at MIT-MC>
To: BUG-LISP at MIT-MC
I forwarded DEVON's bug report to BUG-LISPM where it should have gone.
∂06-Sep-82 1827 Robert Elton Maas <REM at MIT-MC> (LISTEN)
Date: 6 September 1982 21:20-EDT
From: Robert Elton Maas <REM at MIT-MC>
Subject: (LISTEN)
To: BUG-LISP at MIT-MC
Why does (LISTEN) take about 100 miliseconds (0.1 second) to execute?
This seems to be a very long time.
∂07-Sep-82 1329 Glenn S. Burke <GSB at MIT-ML> (LISTEN)
Date: 7 September 1982 16:07-EDT
From: Glenn S. Burke <GSB at MIT-ML>
Subject: (LISTEN)
To: BUG-LISP at MIT-MC
i replied to REM
∂07-Sep-82 1737 Glenn S. Burke <GSB at MIT-MC> suspend tty code fix (tops-20 vts)
Date: 7 September 1982 18:46-EDT
From: Glenn S. Burke <GSB at MIT-MC>
Subject: suspend tty code fix (tops-20 vts)
To: BUG-LISP at MIT-MC
cc: mt at MIT-OZ
According to MT, the problem is that Lisp is setting a whole
word with stmod rather than only the left half as it should;
this can be fixed by making it do RTMOD, and then HLL 2,TI.ST6
rather than the MOVE it now does, at OPNT2+twentysome.
This has been fixed in the source, and patched into the BBLISP on OZ.
We made a .EXE, but did not install it on <SUBSYS> yet (it was in use).
∂07-Sep-82 1738 Skef Wholey <Wholey at CMU-20C> Complr's losing lossage, of course
Date: Tuesday, 7 September 1982 20:14-EDT
From: Skef Wholey <Wholey at CMU-20C>
To: Bug-Complr at MIT-MC
Subject: Complr's losing lossage, of course
Let's see what complr does with the following code:
-----
;;; -*- Lisp -*-
;;;
;;; COMPLR LOSSAGE!!!
;;;
(defconst const-1 0)
(defconst const-2 3)
(defmacro combine-somehow (a b)
`(deposit-byte ,b 28 4 ,a))
(defun fleep ()
(print (combine-somehow const-1 const-2))
(print (combine-somehow const-2 const-1))
(print (combine-somehow 0 3))
(print (combine-somehow 3 0)))
-----
When compiled, (fleep) prints the following:
3
0
3
805306368
Seems a little bogus, huh?
[I realize that no one does much MacLisp maintainence these days, but I just
needed someone to flame at...]
--Skef
∂07-Sep-82 2221 Glenn S. Burke <GSB at MIT-MC> load-byte/deposit-byte miscompilation
Date: 8 September 1982 00:55-EDT
From: Glenn S. Burke <GSB at MIT-MC>
Subject: load-byte/deposit-byte miscompilation
To: Wholey at CMU-20C
cc: BUG-COMPLR at MIT-MC
I have identified the problem in the source, but not tested or
installed the fixes yet (get to it tomorrow). There were a
couple things wrong. Stay tuned...
∂09-Sep-82 0021 GSB@MIT-ML previous patch, to OPNT2
From: GSB@MIT-ML
Date: 09/09/82 03:20:05
Subject: previous patch, to OPNT2
GSB@MIT-ML 09/09/82 03:20:05 Re: previous patch, to OPNT2
To: (BUG LISP) at MIT-ML
is incorrect. I'll publicize the correction when i stop being shafted
by losing hardware, and when i go over it with a Travers
∂13-Sep-82 1324 Kent M. Pitman <KMP at MIT-MC>
Date: 13 September 1982 16:18-EDT
From: Kent M. Pitman <KMP at MIT-MC>
To: ALAN at MIT-MC
cc: BUG-LISP at MIT-MC, bug-oz at MIT-OZ, gsb at MIT-ML
It's sort of a bug in Autokeep (or maybe in Twenex) that you can't set
the Autokeep bit for an entire cluster of files and have it apply to new
versions when written. I think what happened is that when Glenn wrote the
patch the other night to fix SUSPEND lossage, he didn't set the autokeep
bit back on. This was not so much an issue of OZ policy or anything silly
like that as just an easy slip to have happen. This is yet another good
reason why <SUBSYS>MACLISP should probably be an unchanging .EXE file
which does nothing more than reload some other file (such as <MACLISP>'s
MACLISP.EXE). I think this is what is done on EE and I think the reasons
are similar. In any case, sorry for your lost work. It was not intended
that it shouldn't be kept.
-kmp
∂14-Sep-82 1102 Jonathan Alan Solomon <JSol at USC-ECLC>
Date: Tuesday, 14 September 1982 10:52-PDT
From: Jonathan Alan Solomon <JSol at USC-ECLC>
To: David C. Plummer <DCP at MIT-MC>
Cc: ALAN at MIT-MC, BUG-LISP at MIT-MC, bug-oz at MIT-OZ, gsb at MIT-ML,
KMP at MIT-MC
Address: 3737 South Hoover Street Room PHE 204
Los Angeles, California 90089-0273
Phone: (213) 202-1793
Yes for V5, If you save a <SYSTEM>EXEC.EXE properly with this switch
set it will remain set for everyone. Individual users who want to
change it can simply unset it in their COMAND.CMD files.
In my exec there already exists a command to override the file
setting. People seem to be doing SET FILE (no) EPHEMERAL and (no)
AUTOKEEP at random and whenever they feel like it. If you INSTALL LISP
SYS:LISP.EXE AUTOKEEP NO CONFIRM you will *always* get a Kept lisp no
matter what anyone does to the file (this is in my exec under v4).
--JSol
∂14-Sep-82 2252 Stavros M. Macrakis <MACRAK at MIT-MC> < WNA msg
Date: 15 September 1982 01:50-EDT
From: Stavros M. Macrakis <MACRAK at MIT-MC>
Subject: < WNA msg
To: BUG-LISP at MIT-MC
(< 4.5 3)
;4.5 fixnum cant compare to flonum
args=4.5
(return '(4))
...still unhappy...
(return '(3.4))
...happy...
∂17-Sep-82 1643 Glenn S. Burke <GSB at MIT-ML> (status ttysize) on 20X
Date: 17 September 1982 19:44-EDT
From: Glenn S. Burke <GSB at MIT-ML>
Subject: (status ttysize) on 20X
To: ALAN at MIT-MC
cc: BUG-lisp at MIT-MC
Fixed in the source, STATUS 259 (hohoho). The sign bit is used for
(status terpri) on a per-file basis, and things like LINEL and this
code have to be careful to use magnitude only. I will patch this in
on OZ and XX shortly.
(sstatus terpri t [file]) sets this; it is probably being done by something
you load up.
∂17-Sep-82 1658 GSB@MIT-ML (status ttysize) bug, 20x
From: GSB@MIT-ML
Date: 09/17/82 19:46:34
Subject: (status ttysize) bug, 20x
GSB@MIT-ML 09/17/82 19:46:34 Re: (status ttysize) bug, 20x
To: (BUG LISP) at MIT-ML
i should have said, STTYS1+1 should use MOVM rather than MOVE.
∂17-Sep-82 1701 GSB@MIT-ML previous patch
From: GSB@MIT-ML
Date: 09/17/82 19:57:35
Subject: previous patch
GSB@MIT-ML 09/17/82 19:57:35 Re: previous patch
To: (BUG LISP) at MIT-ML
well it's patched in the bblisp on oz.
The scheme dump shares with lisp on the wrong dir so i can't replace
the <maclisp> copy, and XX is wedged in such a way that i can only
get in via telnet which seems to interpret <cr> as <lf> in nddt.
∂01-Oct-82 0404 Kent M. Pitman <KMP at MIT-MC> More data
Date: 1 October 1982 07:01-EDT
From: Kent M. Pitman <KMP at MIT-MC>
Subject: More data
To: BUG-LISP at MIT-MC
cc: JPG at MIT-MC
Well, my feeling is that people shouldn't rely on the exact truth value
which comes back from a true/false predicate. Sad that it ws documented
like that.
By the way, here's some more data. There seems to be a pattern:
Arg1 Arg2 Return Value
A AB T
AB ABC T
ABC ABCD T
ABCD ABCDE T
ABCDE ABCDEF LESSP
ABCDEF ABCDEFG T
ABCDEFG ABCDEFGH T
ABCDEFGH ABCDEFGHI T
ABCDEFGHI ABCDEFGHIJ T
ABCDEFGHIJ ABCDEFGHIJK LESSP
ABCDE ABCDEFG LESSP
Looks like when the characters match exactly up to the length of the first
symbol and the second symbol's pname continues on, the symbol LESSP is
returned. Pretty odd.
∂02-Oct-82 1234 Alan Bawden <ALAN at MIT-MC> ALPHALESSP: More data
Date: 2 October 1982 15:31-EDT
From: Alan Bawden <ALAN at MIT-MC>
Subject: ALPHALESSP: More data
To: BUG-LISP at MIT-MC, JPG at MIT-MC, KMP at MIT-MC
Date: 1 October 1982 07:01-EDT
From: Kent M. Pitman <KMP>
Looks like when the characters match exactly up to the length of the first
symbol and the second symbol's pname continues on, the symbol LESSP is
returned. Pretty odd.
The fix is to patch the MOVEI D,QLESSP at ALPHAL to be MOVE D,VT.ITY
It only seems to matter whether D contains NIL or non-NIL except that the
contents of D get returned in the special case that JPG discovered.